This invention generally relates to data processing systems, and in particular to managing rule sets as web services.
Data processing systems provide facilities to organize and manage large amounts of information. These data processing systems are generally programmed to implement the business processes of a particular enterprise.
In the business field, there is a particular need to acquire and manage large amounts of information for decision making, planning, and operating the business. Each enterprise implements business processes for collecting and managing the information required for that particular enterprise.
Rule management systems provide decision automation based on rule processing. Such systems provide decisions based on testing conditions and can also be used to confirm compliance with a set of rules. More generally, decision automation applies to an activity, a process or a transaction requiring the application of rules or criteria to obtain a result.
Rules are a convenient way to represent decision-making policies. A rule consists of a condition which comprises a combination of tests and actions, which can consist of a sequence of elementary steps.
Existing rule management systems handle the data elements involved in an activity, process or transaction as objects containing attributes. The system creates an object probe from the object where the probe contains a subset of the attributes of the object. The object probe may be passed to a rule to check if the object probe satisfies the conditions of the rule. If the object probe does satisfy the conditions of the rule, a system action can be taken accordingly.
Rules management systems such as Business Rule Management Systems (BRMS) are generally used by business analysts to describe and execute their own rules easily without the help of developers. Conventional BRMS provide one or more servers known as rule execution servers that enable clients to deploy sets of rules and use them at a single endpoint. At a given single endpoint, any rule set can be executed, regardless of its path. The first time a rule set is called, it is instantiated in a pool of rule sets from which it is reused by subsequent requests. Therefore, rule sets do not have to be read and interpreted at each call. This increases the number of transaction per seconds. Generally, this pool of rule sets provides various client Application Programming Interfaces (APIs) to execute a set of data in a rule set.
The current solution for providing rule-based decision services is to add code directly to the execution server in order to provide an interface to the client to enable deployment at a different endpoint address. However, in such static solution, code has to be changed each time the model changes and at each phase of the development: authoring, testing, and production. Accordingly, these rule-based decision services are usually hard-coded by the development team, making them difficult to update and reuse.
In addition, if the decision service is distributed over multiple execution servers in order to provide high availability, the code for the decision must be manually copied, maintained, and kept in synchronization across all servers on which the code is located.
The execution servers themselves may not be of a uniform type, requiring the user to handle each individual case of deployment and management according to the requirements of each system. As a result of the foregoing, creating, developing, and maintaining rule-based decision services can impose a high cost on an organization at all points in the service life-cycle.